A proxy server is a device that acts as an intermediary between a client device and a server to a wide area network (e.g., the Internet). As an intermediary device, the proxy server may interconnect and/or provide communication between the client and the server. In addition to providing a communication path, proxy servers may be used to enforce security or perform other administrative procedures. A proxy server may also provide caching functionality to temporarily store content (e.g., network pages/sites, objects, etc.) that has been previously accessed from the wide area network. A proxy server with caching may be referred to as a cache/caching server or a web cache. A proxy server with caching may store web pages for websites recently “visited” by a client, or retrieved by the server for the client to access. The caching is typically used to manage bandwidth in a network and/or reduce the access time by the client for web browsing.
The proxy server may authenticate a client to verify the identity of the client prior to providing services to the client. Authenticating the client refers to a process in which a client device presents credentials, or certain values/keys, to the proxy. The proxy verifies the credentials with an authenticating procedure, which may involve passing credentials to an authenticating entity and/or service. The authenticating entity may be a device with which the proxy is communicatively coupled, for example, a domain controller that manages client/user accounts. The authentication process may be governed by an agreed-upon protocol, which defines what credentials will be sent, and how the authentication procedure will operate. In a system using a domain controller, the proxy server may receive credentials from a client and pass the credentials to the domain controller to verify the identity of the client.
NTLM (New Technology (NT) LAN (local area network) management) is an authentication protocol developed by Microsoft Corporation of Redmond, Wash. NTLM uses a three stage challenge and response procedure. In the first stage, a client sends a negotiation message to a server referred to as the “NTLMSSP negotiate” message, or simply NTLMSSP (NTLM Security Support Provider) negotiate. In the second stage, the server returns an eight-byte value referred to as the “NTLMSSP challenge” message, or simply the challenge. The challenge is specified to be eight bytes in NTLM, although a different number of bytes may be used in a different implementation, or a modified implementation of NTLM. The client uses the challenge provided and one or more other data items to generate a hash. Specifically, NTLMv1 uses the challenge and a password/passphrase of the client. NTLMv2 uses the challenge, the password/passphrase, and a random number. In the third stage, the client responds to the challenge by sending the hash result, referred to as the “NTLMSSP authentication” message, or simply NTLMSSP auth, to the server. The NTLMSSP auth may also be referred to as the response from the client. In the case of a proxy server, the proxy server forwards the challenge and the hash to the domain controller. The domain controller verifies the response and communicates the result back to the proxy server. If the result communicated back from the domain controller is that the hash matches a result generated at the domain controller, the proxy server authenticates the client.
With NTLM, the authentication process is expected to happen for each request by the client devices. When a system has many client devices, this may mean authentication is requested every time a client device generates a network content request. In an environment where a client device makes many requests, for example, because of browsing many different web pages, the burden on the domain controller may be considerable. As the number of clients increases, the load on the domain controller may be unreasonable for providing adequate, timely service to one or more clients. Thus, in NTLMv1, a proxy server may cache credentials of clients, to reduce the load on the domain controller. The proxy server itself may verify the cached credentials of a client, rather than passing the credentials to the domain controller for each request by the client for web services. Caching client credentials may significantly reduce the burden on the domain controller.
However, for NTLMv2, caching the credentials is ineffective because of the use of a random number in the hash. Because the random number is generated at each separate instance of authentication, the response by the client to the challenge should be expected to be different each time. For this reason, NTLMv2 may be considered an example of a non-cacheable protocol, because the protocol does not support caching of authentication credentials. The protocol may be considered non-cacheable because storing the authentication credentials for later reuse is ineffective at reducing the bandwidth and delay burden incurred by authenticating the client. Specifically for NTLMv2, even if the same challenge were sent each time, the client would be expected to return different hash results each time. Caching the credentials in the proxy server will therefore not operate to reduce the load on the domain controller, because the next hash cannot be expected to match a cached value. In traditional implementations, NTLMv2 can only be executed by authenticating the client with the domain controller for each access request.
Experience in implementing NTLM with cache servers shows that the load on the domain controller can become unworkable in NTLMv1 without credential caching. Because of variability within the authentication process, credential caching is ineffective in NTLMv2, potentially rendering an implementation of NTLMv2 in a cache server system/environment unworkable due to poor performance.